Software Defined Networks ‘SDN’ enable network administrators to manage network services by abstracting lower-level functionalities of the physical network. This is provided by decoupling the system making decisions about where traffic is sent from the underlying system, e.g. switches, that forwards traffic to the selected destination. Software defined networks require procedures for providing a communication between the so-called control plane and the so-called data plane. Such a procedure providing communication between both planes is e.g. the so-called OpenFlow, which is disclosed in the non-patent literature of the Open Networking Foundation (ONF), OpenFlow Switch Specification, Version 1.3.2, Wire Protocol 0x04, Apr. 25, 2013.
In more detail, when packets of a data flow in the SDN are forwarded this involves only the data plane of a switch: Incoming network packets are matched with flow rules installed at the switches and upon matching are forwarded according to rules' specific actions. However, for some packets, the forwarding happens only after some interaction between the data plane of the switch and control plane. More precisely, a switch can be configured to generate a notification event to the control plane upon reception of packets belonging to specified flows. The control plane answers to said notification by generating a forwarding decision, which is installed in the switch's data plane in the form of a flow rule. When the flow rule is installed, the packet is finally forwarded by the switch.
In a software-defined network, the control plane is usually implemented as a remote entity—the so-called controller—and its invocation significantly delays packet forwarding. These delays are intrinsic in software-defined networks because                a) the controller runs on commodity computers and processes the packets in software whereas switches use highly specialized hardware, and        b) installing flow rules in the switches' flow tables is a costly operation.        
By monitoring the network traffic, an attacker can observe these delays and guess—with a considerable probability—for which data flows the controller is invoked. In this way, the attacker may learn how the network is configured and how it operates. The leakage of this information may expose the network to a number of attacks, compromising its security. In more detail in a conventional software-defined network an attacker can measure several features like dispersion, round-trip times, etc. of packet forwarding by observing the network traffic. The attacker can thereby identify—with a very high probability—if the switches have matching flow rules installed for a network packet or if the switches interact with the controller for forwarding the packet. Currently, only prohibitive defenses against making such observations exist, e.g. sending all network packets to the controller or deleting and reinstalling flow rules at the switches. However, these conventional solutions add a significant workload to the controller and the installation of flow rules is a costly operation in terms of network resources, e.g. additional network traffic.